Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

63장. Multi-AZ — 장애 대비의 기본

이 장에서 말하고자 하는 것

DB가 한 대만 있으면

그 DB가 죽음 → 서비스 전체 중단

이걸 해결하는 첫 단계가

Multi-AZ 배포

다.

이 장은 RDS Multi-AZ가 어떻게 동작하고
운영에서 무엇을 보장하는지를 본다.


1. Multi-AZ는 무엇인가

같은 DB를 다른 AZ에 한 대 더 띄워두고 동기 복제 한다.

[AZ-A: Primary (쓰기/읽기)]
       ↓ 동기 복제
[AZ-B: Standby (대기)]

평소에는 Primary만 트래픽을 받는다.
Primary가 죽으면 Standby가 자동으로 Primary가 된다.


2. 자동 페일오버

Primary 장애 감지
  ↓
DNS 레코드가 Standby를 가리키도록 자동 전환
  ↓
애플리케이션은 같은 엔드포인트로 계속 호출

페일오버는 보통 60 ~ 120초 안에 끝난다.

애플리케이션이 자동 재연결을 잘 처리하면 사용자는 잠깐의 끊김만 경험한다


3. 읽기 분산이 아니다

여기서 많이 헷갈리는 부분.

Multi-AZ Standby는 트래픽을 안 받는다

  • 읽기 요청도 Standby로 가지 않는다
  • 단지 장애 대비용으로만 동기 복제된다

읽기를 늘리고 싶다면 Read Replica 가 필요하다 (64장).


4. 비용

Multi-AZ는 사실상 DB를 두 대 띄우는 것과 같다.

컴퓨트 비용: 약 2배
스토리지 비용: 약 2배

운영 서비스에서는 무조건 켠다는 게 일반적이지만
개발 / 테스트 환경에서는 끄는 경우가 많다.


5. Multi-AZ vs Multi-AZ Cluster

RDS는 두 가지 방식의 Multi-AZ를 제공한다.

항목Multi-AZ (기본)Multi-AZ Cluster
노드 수2 (Primary + Standby)3 (Writer + 2 Reader)
Standby로 읽기
페일오버 속도60~120초더 빠름 (수십 초)
지원 엔진모든 RDS 엔진MySQL · PostgreSQL 일부

기본 Multi-AZ 로 시작 → 읽기 부하가 명백히 늘면 Read Replica 또는 Cluster 검토


6. 우리 서비스에서

[ECS "orders"]
   ↓
[RDS PostgreSQL]
 ├─ AZ-A  Primary   (active)
 └─ AZ-B  Standby   (동기 복제)
  • 평소: AZ-A 가 모든 트래픽
  • AZ-A 장애 시: 60~120초 안에 AZ-B 가 Primary

운영 DB는 무조건 Multi-AZ. 비용보다 가용성이 거의 항상 더 비싸다


7. 직접 확인해보기 — CLI

신규 DB에 Multi-AZ

aws rds create-db-instance \
  --db-instance-identifier orders \
  --engine postgres \
  --multi-az \
  ...

기존 DB에 Multi-AZ 켜기

aws rds modify-db-instance \
  --db-instance-identifier orders \
  --multi-az \
  --apply-immediately

이 변경은 다운타임 없이 켜진다.

페일오버 강제 (테스트)

aws rds reboot-db-instance \
  --db-instance-identifier orders \
  --force-failover

운영 환경에서 한 번은 실제로 시켜봐야 한다
페일오버가 정말 잘 동작하는지 / 애플리케이션이 잘 재연결하는지 확인


8. 코드로는 이렇게 생겼다 — Terraform

resource "aws_db_instance" "orders" {
  identifier     = "orders"
  engine         = "postgres"
  engine_version = "16"
  instance_class = "db.t4g.small"

  multi_az                = true   # ← 이 한 줄
  backup_retention_period = 7

  db_subnet_group_name    = aws_db_subnet_group.main.name
  vpc_security_group_ids  = [aws_security_group.db.id]

  publicly_accessible     = false
  deletion_protection     = true
}

multi_az = true 한 줄이 두 AZ에 동기 복제를 켠다.

DB Subnet Group이 두 AZ의 서브넷을 갖고 있어야 한다.


9. 애플리케이션 측 고려사항

페일오버가 일어나면 기존 연결은 끊어진다.

  • 커넥션 풀이 자동 재연결을 지원해야 한다
  • 쓰기 직후 트랜잭션은 실패할 수 있다 → 재시도 로직 필요
  • 읽기 전용 모드를 일부 구간에 두는 게 도움이 될 수 있다

운영 DB에 대한 클라이언트는 항상 “끊어질 수 있다” 를 전제로 설계


10. 이렇게 쓰면 망한다 — 안티패턴

안티패턴 1. 운영 DB에 Multi-AZ 안 켠다

한 AZ 장애로 서비스 전체가 멈춘다.

안티패턴 2. Standby로 읽기를 보낸다고 착각한다

Standby는 트래픽을 안 받는다. 읽기 분산은 Read Replica.

안티패턴 3. 페일오버를 한 번도 시험해보지 않는다

실제 장애 시 애플리케이션이 재연결을 못 해 더 큰 사고가 난다.

정기적으로 force-failover를 시뮬레이션한다

안티패턴 4. DB Subnet Group이 한 AZ만 가진다

Multi-AZ를 켜고 싶어도 안 켜진다.


11. 한 줄로 정리

Multi-AZ는 같은 DB를 다른 AZ에 동기 복제해 두는 장애 대비 구성이며,
운영 DB의 사실상 필수 옵션이다


12. 이 장의 핵심 정리

  1. Multi-AZ는 같은 DB를 다른 AZ에 동기 복제한 형태다.
  2. Primary 장애 시 60~120초 안에 자동 페일오버한다.
  3. Standby는 트래픽을 안 받는다 — 읽기 분산 아님.
  4. 비용은 약 2배지만 가용성이 거의 항상 더 비싸다.
  5. 페일오버는 운영에 들어가기 전 반드시 한 번 시험해본다.